A transaction, in a computer system, is a sequence of information exchange and related work (such as database updating) that is treated as a unit for the purposes of satisfying a request and for ensuring database integrity. For a transaction to be completed and database changes to be made permanent, i.e., a commit transaction, a transaction has to be completed in its entirety. A typical transaction is a catalog merchandise order phoned in by a customer and entered into a computer by a customer representative. The order transaction involves checking an inventory database, confirming that the item is available, placing the order, confirming that the order has been placed, and determining the expected time of shipment. If the above mentioned steps defined a single transaction, then all of the steps must be completed before the transaction is successful. If something happens before the transaction is successfully completed, any changes to the database must be kept track of so that they can be undone, i.e., a rollback transaction.
To ensure that transactions are correctly identified within a computer system that uses them, an application must define and demark the transactions in some way. Specifically, the points of execution at which each transaction begins must be identified, and the points at which each transaction either commits (completes successfully) or rolls back (aborts) must also be identified.
Correct specification of transactions is complicated by the existence of errors within the application, which often are handled by exceptions that cause unexpected transfer of control out of the sequential transaction execution. If the application programmer does not identify all execution paths following the start of a transaction, including all possible error paths, a transaction may be left “dangling” and never end. This situation may cause the application to tie up scarce computer system resources, or to hold locks on critical data. Further, in some cases the error in the transaction coding may also cause a valid transaction to be rolled back if the transaction “times out,” thus giving unintended results.
Additionally, with the growing number of commercial e-commerce applications and enterprise-wide applications today, there exists the notion of a business transaction, distinct from database transactions that are implemented in a Data Base Management System (DBMS). Specifically, business transactions may be implemented as multiple DBMS transactions. This further complicates specification of transactions.
Further, commercial e-commerce applications and enterprise wide applications are typically implemented to use “optimistic concurrency” within the application to avoid long-lived pessimistic transactions, since the latter tend to tie up resources and prevent the throughput and scalability required of e-commerce applications. When optimistic concurrency is used, the programming of transactions becomes even more complicated.
A number of solutions have been developed to simplify the task of specifying transactions. One solution involves inserting an explicit notation within the code of the application to specify the transaction, e.g., there may be a specific command to begin a transaction, and a command to either commit the transaction or roll back the transaction.
For example, applications that access a relational database at the level of Structured Query Language (SQL) queries may use SQL commands “BEGIN TRANSACTION”, “COMMIT WORK”, and “ROLLBACK WORK” to identify the scope of a transaction. To further ease the task of specifying a transaction, many DBMS's provide a simplified notion called “AUTOCOMMIT” whereby each query or method applied to the database implicitly starts a transaction just prior to the query or method call, and automatically commits that transaction upon completing the query or method call. One prior art solution that provides the above described functionality is Java™ Database Connective (JDBC™). Java™ and JDBC™ are pending trademarks of Sun Microsystems®, Inc. located in Palo Alto, Calif.
Another solution developed to simplify the complex task of specifying transactions allows application programmers to identify, on a per-method basis, which method calls must occur within a transaction, and which method calls define a transaction. One prior art solution that provides the above described functionality is Java™ 2 Enterprise Edition (J2EE™) Enterprise Java™ Beans (EJBs). EJBs define deployment descriptors by which the application programmer may specify transactional characteristics, e.g., specify the beginning of a transaction, conditions for a commit transaction, etc. J2EE™ is a pending trademark of Sun Microsystems®, Inc. located in Palo Alto, Calif.